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Abstract 


Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 
(PMIPv6) define mobility management procedures that support unicast 
communication at reduced handover latency. Fast handover base 
operations do not affect multicast communication and, hence, do not 
accelerate handover management for native multicast listeners. Many 
multicast applications like IPTV or conferencing, though, comprise 
delay-sensitive, real-time traffic and will benefit from fast 
handover completion. This document specifies extension of the Mobile 
IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile 
IPv6 (PFMIPv6) protocols to include multicast traffic management in 
fast handover operations. This multicast support is provided first 
at the control plane by management of rapid context transfer between 
access routers and second at the data plane by optional fast traffic 
forwarding that may include buffering. An FMIPv6 access router 
indicates support for multicast using an updated Proxy Router 
Advertisements message format. 


This document updates RFC 5568, "Mobile IPv6 Fast Handovers". 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc741l. 


Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


Mobile IPv6 [RFC6275] defines a network-layer mobility protocol 
involving participation by Mobile Nodes, while Proxy Mobile IPv6 
[RFC5213] provides a mechanism without requiring mobility protocol 
operations at a Mobile Node (MN). Both protocols introduce traffic 
disruptions on handovers that may be intolerable in many real-time 
application scenarios such as gaming or conferencing. Mobile IPv6 
Fast Handovers (FMIPv6) [RFC5568] and Fast Handovers for Proxy Mobile 
IPv6 (PFMIPv6) [RFC5949] improve the performance of handovers for 
unicast communication. Delays are reduced to the order of the 
maximum of the link switching delay and the signaling delay between 
Access Routers (ARs) or Mobile Access Gateways (MAGs) 
[FMIPv6-Analysis]. 


No dedicated treatment of seamless IP multicast [RFC1112] data 
service has been proposed by any of the above protocols. MIPv6 only 
roughly defines multicast for Mobile Nodes using a remote 
subscription approach or a home subscription through bidirectional 
tunneling via the Home Agent (HA). Multicast forwarding services 
have not been specified in [RFC5213] but are subject to separate 
specifications: [RFC6224] and [RFC7287]. It is assumed throughout 
this document that mechanisms and protocol operations are in place to 
transport multicast traffic to ARs. These operations are referred to 
as 'JOIN/LEAVE’ of an AR, while the explicit techniques to manage 
multicast transmission are beyond the scope of this document. 


Mobile multicast protocols need to support applications such as IPTV 
with high-volume content streams and allow distribution to 
potentially large numbers of receivers. They should thus preserve 
the multicast nature of packet distribution and approximate optimal 
routing [RFC5757]. It is undesirable to rely on home tunneling for 
optimizing multicast. Unencapsulated, native multicast transmission 
requires establishing forwarding state, which will not be transferred 
between access routers by the unicast fast handover protocols. Thus, 
multicast traffic will not experience expedited handover performance, 
but an MN -- or its corresponding MAG in PMIPv6 -- can perform remote 
subscriptions in each visited network. 


This document specifies extensions to FMIPv6 and PFMIPv6 that include 
multicast traffic management for fast handover operations in the 
presence of any-source or source-specific multicast. The protocol 
extensions were designed under the requirements that 


o multicast context transfer shall be transparently included in 
unicast fast handover operations; 
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o neither unicast mobility protocols nor multicast routing shall be 
modified or otherwise affected; and 


o no active participation of MNs in PMIPv6 domains is defined. 


The solution common to both underlying unicast protocols defines the 
per-group or per-channel transfer of multicast contexts between ARs 
or MAGs. The protocol defines corresponding message extensions 
necessary for carrying (*,G) or (S,G) context information independent 
of the particular handover protocol. ARs or MAGs are then enabled to 
treat multicast traffic according to fast unicast handovers and with 
Similar performance. No protocol changes are introduced that prevent 
a multicast-unaware node from performing fast handovers with 
multicast-aware ARs or MAGs. 


The specified mechanisms apply when a Mobile Node has joined and 
maintains one or several multicast group subscriptions prior to 
undergoing a fast handover. It does not introduce any requirements 
on the multicast routing protocols in use, nor are the ARs or MAGs 
assumed to be multicast routers. It assumes network conditions, 
though, that allow native multicast reception in both the previous 
and new access network. Methods to bridge regions without native 
multicast connectivity are beyond the scope of this document. 


Section 5.1 of this memo updates the Proxy Router Advertisements 
(PrRtAdv) message format defined in Section 6.1.2 of [RFC5568] to 
allow an FMIPv6 AR to indicate support for multicast. 


1.1. Use Cases and Deployment Scenarios 


Multicast extensions for fast handovers enable multicast services in 
domains that operate either of the unicast fast handover protocols: 


[RFC5568] or [RFC5949]. Typically, fast handover protocols are 
activated within an operator network or within a dedicated service 
installation. 


Multicast group communication has a variety of dominant use cases. 
One traditional application area is infotainment with voluminous 
multimedia streams delivered to a large number of receivers (e.g., 
IPTV). Other time-critical services, such as news items or stock- 
exchange prices, are commonly transmitted via multicast to support 
fair and fast updates. Both of these use cases may be mobile, and 
both largely benefit from fast handover operations. Mobile operators 
may therefore enhance their operational quality or offer premium 
services by enabling fast handovers. 
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Another traditional application area for multicast is conversational 
group communication in scenarios like conferencing or gaming as well 
as in dedicated collaborative environments or teams. Machine-to- 
machine communication in the emerging Internet of Things is expected 
to generate various additional mobile use cases (e.g., among cars). 
High demands on transmission quality and rapidly moving parties may 
require fast handovers. 


Most of the deployment scenarios above are bound to a fixed 
infrastructure with consumer equipment at the edge. Today, they are 
thus likely to follow an operator-centric approach like PFMIPv6. 
However, Internet technologies evolve for adoption in 
infrastructureless scenarios, for example, disaster recovery, rescue, 
crisis prevention, and civil safety. Mobile end-to-end communication 
in groups is needed in Public Protection and Disaster Relief (PPDR) 
scenarios, where mobile multicast communication needs to be supported 
between members of rescue teams, police officers, fire brigade teams, 
paramedic teams, and command control offices in order to support the 
protection and health of citizens. These use cases require fast and 
reliable mobile services that cannot rely on operator infrastructure. 
They are thus expected to benefit from running multicast with FMIPv6. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


This document uses the terminology for mobility entities in 
[RFC5568], [RFC5949], [RFC6275], and [RFC5213]. 


A multicast group is any group (*,G) or (S,G) multicast channel 
listed in a Multicast Listener Report Message. 


3. Protocol Overview 


This section provides an informative overview of the protocol 
mechanisms without normative specifications. 


The reference scenario for multicast fast handover is illustrated in 
Figure 1. A Mobile Node is initially attached to the previous access 
network (P-AN) via the Previous Access Router (PAR) or Previous 
Mobile Access Gateway (PMAG) and moves to the new access network 
(N-AN) connected via a New AR (NAR) or New MAG (NMAG). 
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Figure 1: Reference Network for Fast Handover 
3.1. Multicast Context Transfer between Access Routers 


In a fast handover scenario (see Figure 1), ARs/MAGs establish a 
mutual binding and provide the capability to exchange context 
information concerning the MN. This context transfer will be 
triggered by detecting the forthcoming movement of an MN to a new AR 
and assists the MN to immediately resume communication on the new 
subnet using its previous IP address. In contrast to unicast, 
multicast flow reception does not primarily depend on address and 
binding cache management but requires distribution trees to adapt so 
that traffic follows the movement of the MN. This process may be 
significantly slower than fast handover management [RFC5757]. To 
accelerate the handover, a multicast listener may offer a twofold 
advantage of including the multicast groups under subscription in the 
context transfer. First, the NAR can proactively join the subscribed 
groups as soon as it gains knowledge of them. Second, multicast 
flows can be included in traffic forwarding via the tunnel that is 
established from the PAR to the NAR by the unicast fast handover 
protocol. 
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There are two modes of operation in FMIPv6 and in PFMIPv6. The 
predictive mode allows for AR-binding and context transfer prior to 
an MN handover, while in the reactive mode, these steps are executed 
after detection that the MN has reattached to a NAR (NMAG). Details 
of the signaling schemes differ between FMIPv6 and PFMIPv6 and are 
outlined in Sections 3.2 and 3.3. 


In a predictive fast handover, the access router (i.e., PAR (PMAG) in 
Figure 1) learns about the impending movement of the MN and 
simultaneously about the multicast group context as specified in 
Sections 3.2 and 3.3. Thereafter, the PAR will initiate an AR- 
binding and context transfer by transmitting a Handover Initiation 


(HI) message to the NAR (NMAG). The HI message is extended by 
multicast group states carried in mobility header options, as defined 
in Section 5.3. On reception of the HI message, the NAR returns a 


multicast acknowledgement in its Handover Acknowledgement (HAck) 
answer that indicates its ability to support each requested group 
(see Section 5.4). The NAR (NMAG) expresses its willingness to 
receive multicast traffic forwarded by the PAR using standard 
Multicast Listener Discovery (MLD) signaling for IPv6 or the Internet 
Group Management Protocol (IGMP) for an IPv4 compatibility case. 


Nodes normally create forwarding state for each group requested. 
There are several reasons why a node may decide not to forward a 
specific group, e.g., the NAR could already have a native 
subscription for the group(s) or capacity constraints can hinder 
decapsulation of additional streams. At the previous network, there 
may be policy or capacity constraints that make it undesirable to 
forward the multicast traffic. The PAR can add the tunnel interface 
obtained from the underlying unicast protocol to its multicast 
forwarding database for those groups the MN wishes to receive, so 
that multicast flows can be forwarded in parallel to the unicast 
traffic. 


The NAR implements an MLD proxy [RFC4605] providing host-side 
behavior towards the upstream PAR. The proxy will submit an MLD 
report to the upstream tunnel interface to signal the set of groups 
to be forwarded. It will terminate multicast forwarding from the 
tunnel when the group is natively received. In parallel, the NAR 
joins all groups that are not already under subscription using its 
native multicast upstream interface. While the MN has not arrived at 
a downstream interface of the NAR, multicast subscriptions on behalf 
of the MN are associated with a downstream loopback interface. 
Reception of the Join at the NAR enables downstream native multicast 
forwarding of the subscribed group(s). 
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In a reactive fast handover, the PAR will learn about the movement of 
the MN after the latter has re-associated with the new access 
network. Also, from the new link, it will be informed about the 
multicast context of the MN. As group membership information is 
present at the new access network prior to context transfer, MLD join 
signaling can proceed in parallel to HI/HAck exchange. Following the 
context transfer, multicast data can be forwarded to the new access 
network using the PAR-NAR tunnel of the fast handover protocol. 
Depending on the specific network topology, multicast traffic for 
some groups may natively arrive before it is forwarded from the PAR. 


In both modes of operation, it is the responsibility of the PAR 
(PMAG) to properly apply multicast state management when an MN leaves 
(i.e., to determine whether it can prune the traffic for any 
unsubscribed group). Depending on the link type and MLD parameter 
settings, methods for observing the departure of an MN need to be 
applied (see [RFC5757]). While considering subscriptions of the 
remaining nodes and from the tunnel interfaces, the PAR uses normal 
multicast forwarding rules to determine whether multicast traffic can 
be pruned. 


This method allows an MN to participate in multicast group 
communication with a handover performance that is comparable to 
unicast handover. It is worth noting that tunnel management between 
access routers in all modes is inherited from the corresponding 
unicast fast handover protocols. Tunnels thus remain active until 
unicast handover operations have been completed for the MN. 


3.2. Protocol Operations Specific to FMIPv6 


ARs that provide multicast support in FMIPv6 will advertise this 
general service by setting an indicator bit (’M’ bit) in its PrRtAdv 
message, as defined in Section 5.1. Additional details about the 
multicast service support, e.g., flavors and groups, will be 
exchanged within HI/HAck dialogs later at handover. 


An MN operating FMIPv6 will actively initiate the handover management 
by submitting a Fast Binding Update (FBU). The MN, which is aware of 
the multicast groups it wishes to maintain, will attach mobility 
options containing its group states (see Section 5.3) to the FBU and 
thereby inform ARs about its multicast context. ARs will use these 
multicast context options for inter-AR context transfer. 


In predictive mode, the FBU is issued on the previous link and 
received by the PAR as displayed in Figure 2. The PAR will extract 
the multicast context options and append them to its HI message. 
From the HAck message, the PAR will redistribute the multicast 
acknowledgement by adding the corresponding mobility options to its 
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Fast Binding ACK (FBack) message. From receiving the FBack message, 
the MN will learn about the multicast support for each group in the 
new access network. If some groups or multicast service models are 
not supported, it can decide to take actions to overcome a missing 
service (e.g., by tunneling). Note that the proactive multicast 
context transfer may proceed successfully, even if the MN misses the 
FBack message on the previous link. 


MN PAR NAR 
| | | 
| ------ RtSolPr------- >| | 
|<----- PrRtAdv-------- | | 
| | | 
| | | 
|--------- FBU-------- > | ---------- HI--------- > | 


| |<-------- HAck--------- | 

| | (Multicast AckOpt) | 

| | Join to 

| | Multicast 

| | Groups 

| 

| <----- FBack--- | --FBack------ > | 

| (Multicast AckOpt) | (Multicast AckOpt) | 

| | | 
disconnect optional 

packet > 
forwarding 

| | | 
connect | | 

| | | 

| ------------ UNA --------------------------- > | 

< deliver packets 


Figure 2: Predictive Multicast Handover for FMIPv6 


The flow diagram for reactive mode is depicted in Figure 3. After 
attaching to the new access link and performing an Unsolicited 
Neighbor Advertisement (UNA), the MN issues an FBU that the NAR 
forwards to the PAR without processing. At this time, the MN is able 
to rejoin all subscribed multicast groups without relying on AR 
assistance. Nevertheless, multicast context options are exchanged in 
the HI/HAck dialog to facilitate intermediate forwarding of the 
requested multicast flows. The multicast traffic could arrive from 
an MN subscription at the same time that the NAR receives the HI 
message. Such multicast flows may be transparently excluded from 
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forwarding by setting an appropriate Multicast Acknowledgement 
Option. In either case, to avoid duplication, the NAR MUST ensure 
that not more than one flow of the same group is forwarded to the MN. 


MN PAR NAR 
| | | 
| ------ Rt SolPr------- >| | 
|<----- PrRtAdv-------- | | 
| 

disconnect 
| | | 
| | | 
connect | | 
| ------- UNA----------- | --------------------- > | 
|------- FBU----------- [sans ) | 
(Multicast MobOpt) Lo FBU---------- j 
Join to | | 
Multicast | | 
Groups | | 
| |---------- Al >| 
(Multicast MobOpt) 
<= HACk-========== 
| | (Multicast AckOpt) | 
| | | 
| | (HI/HAck if necessary) | 
| | | 
FBack, optional 
packet forwarding ==========> 
| | | 
|< deliver packets 
| 


Figure 3: Reactive Multicast Handover for FMIPv6 
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3.3. Protocol Operations Specific to PFMIPv6 


In a proxy mobile IPv6 environment, the MN remains agnostic of 
network layer changes, and fast handover procedures are operated by 
the access routers or MAGs to which MNs are connected via node- 
specific point-to-point links. The handover initiation, or the re- 
association, is managed by the access networks. Consequently, access 
routers need to be aware of multicast membership state at the Mobile 
Node. There are two ways to obtain the multicast membership of an 
MN. 


o MAGs may perform explicit tracking (see [RFC4605] and [RFC6224]) 
or extract membership status from forwarding states at node- 
specific links. 


o routers can issue a general MLD query at handovers. Both methods 
are equally applicable. However, a router that does not provide 
explicit membership tracking needs to query its downstream links 
after a handover. The MLD membership information then allows the 
PMAG to learn the multicast group subscriptions of the MN. 


In predictive mode, the PMAG will learn about the upcoming movement 
of the Mobile Node, including its new Access Point Identifier (New AP 
ID). Without explicit tracking, it will immediately submit a general 
MLD query and receive MLD reports indicating the multicast address 
listening state of the subscribed group(s). As displayed in 

Figure 4, it will initiate binding and context transfer with the NMAG 
by issuing a HI message that is augmented by multicast contexts in 
the mobility options defined in Section 5.3. NMAG will extract 
multicast context information and act as described in Section 3.1. 
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PMAG NMAG 
MN P-AN N-AN (PAR) (NAR) 
| Report | | | 
|--- (MN ID,-->| | | | 
| New AP ID) | | | | 
| | HO Indication | | 
| |-- (MN ID, New AP 1D)-->| | 
| | | Optional: | 
| | | MLD Query | 
| | | | 
| | | |------81----> | 
| | | | (Multicast MobOpt) 
| | | | 
<---HAck----- | 
(Multicast AckOpt) 
| | | | 
| | | | Join to 
| | | | Multicast 
| | | | Groups 
| | | OO 
| | | eo > 
| | | | | 
| | | optional packet | 
| | | forwarding =======> | 
disconnect | | 
connect | | | | 
| MN-AN connection | AN-MAG connection | 
|<----establishment----- >|<----establishment------- >| 
| | (substitute for UNA) | 
| | | 
< deliver packets 


Figure 4: Predictive Multicast Handover for PFMIPv6 


In reactive mode, the NMAG will learn the attachment of the MN to the 
N-AN and establish connectivity using the PMIPv6 protocol operations. 
However, it will have no knowledge about multicast state at the MN. 
Triggered by an MN attachment, the NMAG will send a general MLD query 
and thereafter join the groups for which it receives multicast 


listener report messages. In the case of a reactive handover, the 
binding is initiated by the NMAG, and the HI/HAck message semantic is 
inverted (see [RFC5949]). For multicast context transfer, the NMAG 


attaches to its HI message those group identifiers it requests to be 
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forwarded from PMAG. Using the identical syntax in its Multicast 
Mobility Option headers, as defined in Section 5.4, the PMAG 
acknowledges the set of requested groups in a HAck answer, indicating 
the group(s) it is willing to forward. The corresponding call flow 
is displayed in Figure 5. 


PMAG NMAG 
MN P-AN N-AN (PAR) (NAR) 
| 
disconnect 
| | | 
connect | | | 
| 
| 


<---establishment---->|<----establishment------- > 


MN-AN connection AN-MAG connection | 
(substitute for UNA & w 


MLD Query 


Multicast 


| 
| 
| Join to 
| 
| Groups 


| 
| (Multicast MobOpt) 
| 
|- 
(Multicast AckOpt) 
| 


| 
| HI/HAck (optional) 
| 
| 


optional packet 
forwarding =======> 


< deliver packets 


Figure 5: Reactive Multicast Handover for PFMIPv6 
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4. Protocol Details 


This section provides a normative definition of the protocol 
operations. 


4.1. Protocol Operations Specific to FMIPv6 
4.1.1. Operations of the Mobile Node 


A Mobile Node willing to manage multicast traffic by fast handover 
operations MUST transfer its MLD listener state records within fast 
handover negotiations. 


When sensing a handover in predictive mode, an MN MUST build a 
Multicast Mobility Option, as described in Section 5.3, that contains 
the MLD or IGMP multicast listener state and append it to the Fast 
Binding Update (FBU) prior to signaling with PAR. 


The MN will receive the Multicast Acknowledgement Option(s) as a part 
of the Fast Binding Acknowledge (FBack) (see Section 5.4) and learn 
about unsupported or prohibited groups at the NAR. The MN MAY take 
appropriate actions such as home tunneling to enable reception of 
groups that are not available via the NAR. Beyond standard FMIPv6 
signaling, no multicast-specific operation is required by the MN when 
reattaching in the new network. 


In reactive mode, the MN MUST append the identical Multicast Mobility 
Option to the FBU sent after its reconnect. In response, it will 
learn about the Multicast Acknowledgement Option(s) from the FBack 
and expect corresponding multicast data. Concurrently, it joins all 
subscribed multicast groups directly on its newly established access 
link. 


4.1.2. Operations of the Previous Access Router 


A PAR that supports multicast advertises that support by setting the 
'M’ bit in the Proxy Router Advertisement (PrRtAdv) message, as 
specified in Section 5.1 of this document. This indicator 
exclusively informs the MNs about the capability of the PAR to 
process and exchange Multicast Mobility Options during fast handover 
operations. 


In predictive mode, a PAR will receive the multicast listener state 
of an MN prior to handover from the Multicast Mobility Option 
appended to the FBU. It forwards these records to the NAR within HI 
messages and will expect Multicast Acknowledgement Option(s) ina 
HAck, which is itself returned to the MN as an appendix to the FBack. 
In performing the multicast context exchange, the PAR is instructed 


Schmidt, et al. Experimental [Page 15] 


RFC 7411 Multicast for FMIPv6/PFMIPv6 November 2014 


to include the PAR-to-NAR tunnel obtained from unicast handover 
management in its multicast downstream interfaces and awaits 
reception of multicast listener report messages from the NAR. In 
response to receiving multicast subscriptions, the PAR SHOULD forward 
group data acting as a regular multicast router or proxy. However, 
the PAR MAY refuse to forward some or all of the multicast flows 
(e.g., due to administrative configurations or load conditions). 


In reactive mode, the PAR will receive the FBU augmented by the 
Multicast Mobility Option from the new network but continues with an 
identical multicast record exchange in the HI/HAck dialog. As in the 
predictive case, it configures the PAR-to-NAR tunnel for the 
multicast downstream. It then (if capable) forwards data according 
to the group membership indicated in the multicast listener report 
messages received from NAR. 


In both modes, the PAR MUST interpret the first of the two events -- 
the departure of the MN or the reception of the Multicast 
Acknowledgement Option(s) -- as if the MN had sent a multicast LEAVE 
message and react according to the signaling scheme deployed in the 
access network (i.e., MLD querying, explicit tracking). 


4.1.3. Operations of the New Access Router 


A NAR that supports multicast advertises that support by setting the 
‘'M’ bit in PrRtAdv as specified in Section 5.1 of this document. 
This indicator exclusively serves the purpose of informing MNs about 
the capability of the NAR to process and exchange Multicast Mobility 
Options during fast handover operations. 


In predictive mode, a NAR will receive the multicast listener state 
of an expected MN from the Multicast Mobility Option appended to the 
HI message. It will extract the multicast group membership records 
from the message and match the request subscription with its 
multicast service offer. Further on, it will join the requested 
groups using a downstream loopback interface. This will lead to 
suitable regular subscriptions to a native multicast upstream 
interface without additional forwarding. Concurrently, the NAR 
builds a Multicast Acknowledgement Option(s) (see Section 5.4) 
listing the set of groups that are unsupported on the new access link 
and returns this list within a HAck. As soon as there is an 
operational bidirectional tunnel from the PAR to NAR, the NAR joins 
the groups requested by the MN, which are then forwarded by the PAR 
using the tunnel link. 


In reactive mode, the NAR will learn about the multicast listener 
state of a new MN from the Multicast Mobility Option appended to each 
HI message after the MN has already performed local subscriptions of 
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the multicast service. Thus, the NAR solely determines the 
intersection of requested and supported groups and issues a join 
request for each group forwarding this on the PAR-NAR tunnel 
interface. 


In both modes, the NAR MUST send a LEAVE message to the tunnel when 
it is no longer needed to forward a group, e.g., after arrival of 
native multicast traffic or termination of a group membership from 
the MN. Although the message can be delayed, immediately sending the 
LEAVE message eliminates the need for the PAR and NAR to process 
traffic that is not to be forwarded. 


4.1.4. Buffering Considerations 


Multicast packets may be lost during handover. For example, in 
predictive mode, as illustrated by Figure 2, packets may be lost 
while the MN is -- already or still -- detached from the networks, 
even though they are forwarded to the NAR. In reactive mode as 
illustrated by Figure 3, the situation may be worse, since there will 
be a delay before joining the multicast group after the MN reattaches 
to the NAR. Multicast packets cannot be delivered during this time. 
Buffering the multicast packets at the PAR can reduce multicast 
packet loss but may then increase resource consumption and delay in 
packet transmission. Implementors should balance the different 
requirements in the context of predominant application demands (e.g., 
real-time requirements or loss sensitivity). 


4.2. Protocol Operations Specific to PFMIPv6 
4.2.1. Operations of the Mobile Node 


A Mobile Node willing to participate in multicast traffic will join, 
maintain, and leave groups as if located in the fixed Internet. It 
will cooperate in handover indication as specified in [RFC5949] and 
required by its access link-layer technology. No multicast-specific 
mobility actions nor implementations are required at the MN ina 
PMIPv6 domain. 


4.2.2. Operations of the Previous MAG 


A MAG receiving a handover indication for one of its MNs follows the 
same predictive fast handover mode as a PMAG. It MUST issue an MLD 
General Query immediately on its corresponding link unless it 
performs explicit membership tracking on that link. After knowledge 
of the multicast subscriptions of the MN is acquired, the PMAG builds 
a Multicast Mobility Option, as described in Section 5.3, that 
contains the MLD and IGMP multicast listener state. If not empty, 
this Mobility Option is appended to the regular fast handover HI 
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messages. In the case when a unicast HI message is submitted prior 
to multicast state detection, the multicast listener state is sent in 
an additional HI message to the NMAG. 


The PMAG then waits until it receives the Multicast Acknowledgement 
Option(s) with a HAck message (see Section 5.4) and the bidirectional 
tunnel with the NMAG is created. After the HAck message is received, 
the PMAG adds the tunnel to its downstream interfaces in the 
multicast forwarding database. For those groups reported in the 
Multicast Acknowledgement Option(s), i.e., not supported in the new 
access network, the PMAG normally takes appropriate actions (e.g., 
forwarding and termination) according to the network policy. It 
SHOULD start forwarding multicast traffic down the tunnel interface 
for the groups indicated in the multicast listener reports received 
from NMAG. However, it MAY deny forwarding some or all groups 
included in the multicast listener reports (e.g., due to 
administrative configurations or load conditions). 


After the departure of the MN and on the reception of a LEAVE 
message, it is RECOMMENDED that the PMAG terminates forwarding of the 
specified groups and updates its multicast forwarding database. It 
correspondingly sends a LEAVE message to its upstream link for any 
group where there are no longer any active listeners on any 
downstream link. 


A MAG receiving a HI message with the Multicast Mobility Option for a 
currently attached node follows the reactive fast handover mode as a 
PMAG. It will return a Multicast Acknowledgement Option(s) (see 
Section 5.4) within a HAck message listing the groups for which it 
does not provide forwarding support to the NMAG. It will add the 
bidirectional tunnel with NMAG to its downstream interfaces and will 
start forwarding multicast traffic for the groups listed in the 
multicast listener report messages from the NMAG. On reception of a 
LEAVE message for a group, the PMAG terminates forwarding for the 
specific group and updates its multicast forwarding database. 
According to its multicast forwarding state, it sends a LEAVE message 
to its upstream link for any group where there are no longer any 
active listeners on any downstream link. 


In both modes, the PMAG will interpret the departure of the MN as a 
multicast LEAVE message of the MN and react according to the 
signaling scheme deployed in the access network (i.e., MLD querying 
and explicit tracking). 
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4.2.3. Operations of the New MAG 


A MAG receiving a HI message with a Multicast Mobility Option for a 
currently unattached node follows the same predictive fast handover 
mode as an NMAG. It will decide the multicast groups to be forwarded 
from the PMAG and build a Multicast Acknowledgement Option (see 
Section 5.4) that enumerates only unwanted groups. This Mobility 
Option is appended to the regular fast handover HAck messages or, in 
the case of a unicast HAck message being submitted prior to multicast 
state acknowledgement, sent in an additional HAck message to the 
PMAG. Immediately thereafter, the NMAG SHOULD update its MLD 
membership state based on the membership reported in the Multicast 
Mobility Option. Until the MN reattaches, the NMAG uses its Loopback 
interface for downstream and MUST NOT forward traffic to the 
potential link of the MN. The NMAG SHOULD issue JOIN messages for 
those newly selected groups to its regular multicast upstream 
interface. As soon as the bidirectional tunnel with PMAG is 
established, the NMAG additionally joins those groups on the tunnel 
interface requested to be forwarded from the PMAG. 


A MAG experiencing a connection request for an MN without prior 
reception of a corresponding Multicast Mobility Option is operating 
in the reactive fast handover mode as an NMAG. Following the 
reattachment, it SHOULD immediately issue an MLD General Query to 
learn about multicast subscriptions of the newly arrived MN. Using 
standard multicast operations, the NMAG joins groups not currently 
forwarded using its regular multicast upstream interface. 
Concurrently, it selects groups for forwarding from PMAG and builds a 
Multicast Mobility Option, as described in Section 5.3, that contains 
the multicast listener state. If not empty, this Mobility Option is 
appended to the regular fast handover HI messages with the F flag set 
or, in the case of unicast HI message being submitted prior to 
multicast state detection, sent in an additional HI message to the 
PMAG. Upon reception of the Multicast Acknowledgement Option and 
establishment of the bidirectional tunnel, the NMAG additionally 
joins the set of groups on the tunnel interface that it wishes to 
receive by forwarding from the PMAG. When multicast flows arrive, 
the NMAG forwards data to the appropriate downlink(s). 


In both modes, the NMAG MUST send a LEAVE message to the tunnel when 
forwarding of a group is no longer needed, e.g., after native 
multicast traffic arrives or group membership of the MN terminates. 
Although the message can be delayed, immediately sending the LEAVE 
message eliminates the need for PAR and NAR to process traffic that 
is not to be forwarded. 
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DA 


.2.4. IPv4 Support Considerations 


An MN in a PMIPv6 domain MAY use an IPv4 address transparently for 
communication, as specified in [RFC5844]. For this purpose, Local 
Mobility Anchors (LMAs) can register IPv4-Proxy-CoAs in its binding 
caches, and MAGs can provide IPv4 support in access networks. 
Correspondingly, multicast membership management will be performed by 
the MN using IGMP. For multiprotocol multicast support on the 
network side, IGMPv3 router functions are required at both MAGs (see 
Section 5.6 for compatibility considerations with previous IGMP 
versions). Context transfer between MAGs can transparently proceed 
in the HI/HAck message exchanges by encapsulating IGMP multicast 
state records within Multicast Mobility Options (see Sections 5.3 and 
5.4 for details on message formats). 


The deployment of IPv4 multicast support SHOULD be homogeneous across 
a PMIP domain. This avoids multicast service breaks during 
handovers. 


It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access 
network and the use of Generic Routing Encapsulation (GRE) tunneling 
as specified in [RFC5845]. Corresponding implications and operations 
are discussed in the PMIP Multicast Base Deployment document (see 
[RFC6224]). 


Message Formats 


.1. Multicast Indicator for Proxy Router Advertisement (PrRtAdv) 


This document updates the Proxy Router Advertisements (PrRtAdv) 
message format defined in Section 6.1.2 of [RFC5568]. The update 
assigns the first bit of the Reserved field to carry the ’M’ bit, as 
defined in Figure 6. An FMIPv6 AR indicates support for multicast by 
setting the ’M’ bit to a value of 1. 


0 dh 2 3 

0 e2 3) 4.25678 9 Oo B ES E 56 P28 e S O 2 3-4 5.6 418.79 0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
| Type | Code | Checksum 
YH A A O AO O O O O A O A O A O A O A O A O O A O A O + + 
| Subtype |M] Reserved | Identifier 

ot ato A toto O O O O toto A O A O A O A O tata tata A O A O + + 
| Options 

+-+-+-+-+-+-+-+-+-+-+-+- 


Figure 6: Multicast Indicator Bit for Proxy Router Advertisement 
(PrRtAdv) Message 
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This document updates the Reserved field to include the 'M” bit. It 
is specified as follows. 


M 1 indicates that the specifications of this document apply. 


M = 0 indicates that the behavior during fast handover proceeds 
according to [RFC5568]. 


The default value (0) of this bit indicates a non-multicast-capable 
service. 


5.2. Extensions to Existing Mobility Header Messages 


The fast handover protocols use an IPv6 header type called Mobility 
Header, as defined in [RFC6275]. Mobility Headers can carry variable 
Mobility Options. 


The multicast listener context of an MN is transferred in fast 
handover operations from PAR/PMAG to NAR/NMAG within a new Multicast 
Mobility Option and MUST be acknowledged by a corresponding Multicast 
Acknowledgement Option. Depending on the specific handover scenario 
and protocol in use, the corresponding option is included within the 
mobility option list of HI/HAck only (PFMIPv6) or of FBU/FBack/HI/ 
HAck (FMIPv6). 


5.3. New Multicast Mobility Option 


This section defines the Multicast Mobility Option. It contains the 
current listener state record of the MN obtained from the MLD 
Multicast Listener Report message and has the format displayed in 
Figure 7. 
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0 Í 2 3 
O S ES E 56:78 90:1.2 34-356 Y 8 9:01. e S O 6.7 8 OO 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Type | Length | Option-Code | Reserved 
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+ 
| 
+ 
| 
+ 
| 
+ 


: +— + — + — 


MLD or IGMP Report Payload 


| 
a ecos 
Figure 7: Mobility Header Multicast Option 
Type: 60 
Length: 8-bit unsigned integer. The length of this option in 32-bit 
words, not including the Type, Length, Option-Code, and Reserved 
fields. 
Option-Code: 
1: IGMPv3 Payload Type 
2: MLDv2 Payload Type 
3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode 
4: MLDv2 Payload Type from MLDv1 Compatibility Mode 


Reserved: MUST be set to zero by the sender and MUST be ignored by 
the receiver. 


MLD or IGMP Report Payload: This field is composed of the Membership 
Report message after stripping its ICMP header. This Report Payload 
always contains an integer number of multicast records. 
Corresponding message formats are defined for MLDv2 in [RFC3810] and 
for IGMPv3 in [RFC3376]. This field MUST always contain the first 
header line (Reserved field and No of Mcast Address Records). 
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Figure 8 shows the Report Payload for MLDv2 (see Section 5.2 of 
[RFC3810] for the definition of Multicast Address Records). When 
IGMPv3 is used, the payload format is defined according to IGMPv3 
Group Records (see Section 4.2 of [RFC3376] for the definition of 
Group Records). 


0 1 2 3 
OT 223) 4 0976 7:8 9.00. Ts 2°53. 4 -E 7-8. 940 12 3 4 E 1:28 9:01 
Fatt tata tata a a o o E E 
| Reserved |No of Mcast Address Records (M) | 
Fatt ata ta tata tartar a o o o o O 
| | 


Multicast Address Record (1) 
+-+-4-4+-+-+4+-4+-+-+-4+-4+-+4-4-4+-4+-4+-4+-4+-+4-4+-4+-4+-+4+-4+-4+-4+-4-4+-+4-4-4+-4-4+ 
Multicast Address Record (2) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


+-+-4+-4+-+-+4+-4+-+-+-4-4+-+4-4+-4+-+-+4+-4-4+-+4-4-4+-4+-+4+-4+-4+-4+-4-4+-+-4+-4+-4-4+ 
Multicast Address Record (M) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 8: MLDv2 Report Payload 
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5.4. New Multicast Acknowledgement Option 


The Multicast Acknowledgement Option reports the status of the 
context transfer and contains the list of state records that could 
not be successfully transferred to the next access network. It has 
the format displayed in Figure 9. 


0 1 2 3 
0123456789012345678°90123456789021 
Poo Fo Fo Fifi F iti fifi NN ggg agate 
Type | Length | Option-Code | Status 
NN NN agate 


MLD or IGMP Unsupported Report Payload 


: +— + — + — 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 9: Mobility Header Multicast Acknowledgement Option 
Type: 61 
Length: 8-bit unsigned integer. The length of this option in 32-bit 
words, not including the Type, Length, Option-Code, and Status 
fields. 
Option-Code: 0 
Status: 
1: Report Payload type unsupported 
2: Requested group service unsupported 
3: Requested group service administratively prohibited 
MLD or IGMP Unsupported Report Payload: This field is syntactically 
identical to the MLD and IGMP Report Payload field described in 
Section 5.3 but is only composed of those Multicast Address Records 
that are not supported or prohibited in the new access network. This 
field MUST always contain the first header line (Reserved field and 


No of Mcast Address Records) but MUST NOT contain any Mcast Address 
Records if the status code equals 1. 
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Note that group subscriptions to specific sources may be rejected at 
the destination network; thus, the composition of multicast address 


records may differ from initial requests within an MLD or IGMP Report 
Payload option. 


5.5. Length Considerations: Number of Records and Addresses 


Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs 
impose length restrictions on multicast context records due to the 
8-bit Length field. The maximal payload length available in FBU/ 
FBack messages is 4 octets (Mobility Option header line) + 1024 


octets (MLD Report Payload). For example, not more than 51 Multicast 
Address Records of minimal length (without source states) may be 
exchanged in one message pair. In typical handover scenarios, this 


number reduces further according to unicast context and Binding 
Authorization data. A larger number of MLD reports that exceeds the 
available payload size MAY be sent within multiple HI/HAck or FBU/ 
FBack message pairs. In PFMIPv6, context information can be 
fragmented over several HI/HAck messages. However, a single MLDv2 
Report Payload MUST NOT be fragmented. Hence, for a single Multicast 


Address Record, the number of source addresses (S,.) is limited to 
62. 


5.6. MLD and IGMP Compatibility Requirements 


Access routers (MAGs) MUST support MLDv2 and IGMPv3. To enable 
multicast service for MLDv1 and IGMPv2 listeners, the routers MUST 
follow the interoperability rules defined in [RFC3810] and [RFC3376] 
and appropriately set the Multicast Address Compatibility Mode. 


When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a 
router internally translates the subsequent MLDv1 and IGMPv2 messages 
for that multicast address to their MLDv2 and IGMPv3 equivalents and 
uses these messages in the context transfer. The current state of 
Compatibility Mode is translated into the code of the Multicast 
Mobility Option, as defined in Section 5.3. A NAR (NMAG) receiving a 
Multicast Mobility Option during handover will switch to the lowest 
level of MLD and IGMP Compatibility Mode that it learned from its 
previous and new option values. This minimal compatibility agreement 
is used to allow for continued operation. 
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6. Security Considerations 


Security vulnerabilities that exceed issues discussed in the base 
protocols mentioned in this document ([RFC5568], [RFC5949], 
[RFC3810], and [RFC3376]) are identified as follows. 


Multicast context transfer at predictive handovers implements group 
states at remote access routers and may lead to group subscriptions 
without further validation of the multicast service requests. 
Thereby, a NAR (NMAG) is requested to cooperate in potentially 
complex multicast rerouting and may receive large volumes of traffic. 
Malicious or inadvertent multicast context transfers may result ina 
significant burden of route establishment and traffic management onto 
the backbone infrastructure and the access router itself. Rapid 
rerouting or traffic overload can be mitigated by a rate control at 
the AR that restricts the frequency of traffic redirects and the 
total number of subscriptions. In addition, the wireless access 
network remains protected from multicast data injection until the 
requesting MN attaches to the new location. 


7. IANA Considerations 
This document defines two new mobility options that have been 
allocated from the "Mobility Options" registry at 
<http://www.iana.org/assignments/mobility-parameters>: 
60 Multicast Mobility Option, described in Section 5.3 
61 Multicast Acknowledgement Option, described in Section 5.4 
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Appendix A. Considerations for Mobile Multicast Sources 


This document only specifies protocol operations for fast handovers 
for mobile listeners. In this appendix, we briefly discuss aspects 
of supporting mobile multicast sources. 


In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender 
support is likely to be enabled by any one of the mechanisms 
described in [RFC7287]. In this case, multicast data packets from an 
MN are transparently forwarded either to its associated LMA or to a 
multicast-enabled access network. In all cases, a mobile source can 
continue to transmit multicast packets after a handover from PMAG to 
NMAG without additional management operations. Packets (with a 
persistent source address) will continue to flow via the LMA or the 
access network into the previously established distribution system. 


In contrast, an MN will change its Care-of Address while performing 
FMIPv6 handovers. Even though MNs are enabled to send packets via 
the reverse NAR-PAR tunnel using their previous Care-of Address for a 
limited time, multicast sender support in such a Mobile IPv6 regime 
will most likely follow one of the basic mechanisms described in 
Section 5.1 of [RFC5757]: (1) bidirectional tunneling, (2) remote 
subscription, or (3) agent-based solutions. A solution for multicast 
senders that is homogeneously deployed throughout the mobile access 
network can support seamless services during fast handovers, the 
details of which are beyond the scope of this document. 
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